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METHOD AND SYSTEM FOR AUTOMATIC LOAD BALANCING OF 
ADVERTISED SERVICES BY SERVICE INFORMATION PROPAGATION 
BASED ON USER ON-DEMAND REQUESTS 



1. Field of the Invention 

The present invention relates to an improved data 
processing system and, in particular, to a method and 
apparatus for enhancing network services. Still more 
particularly, the present invention provides a method and 
system for configuration and allocation of networked 
resources . 

2. Description of Related Art 

In a highly distributed computational system, the 
applications that perform operations for a given network 
service may be dispersed on physical devices throughout 
the network. Applications on other physical devices that 
desire access to the given network service must be 
provided with information on the manner in which a 
connection with the network service can be obtained. 

A complete inventory of available networked 
resources may be distributed throughout the system. In a 
system in which networked resources are continually going 
online and offline, a significant amount of attention 
must be given to dispersing information about the 
availability of networked resources and their location, 
both physical location and logical location or 
organization. 
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In any given network, the demand for networked 
resources fluctuates over time. In a highly distributed 
computing system, all of the computer platforms may have 
varying needs for networked resources, thereby creating a 
very dynamic environment for managing networked 
resources . 

Generally, network management software within the 
distributed computing system satisfies the demand for 
networked resources using some type of load balancing 
such that all service requesters eventually get access to 
the requested service. It is sometimes critical to load 
balance the demand for services by distributing the 
request workload across the entire system in order to 
ensure fair access . 

When multiple concurrent access is needed to satisfy 
the request workload, most existing systems only rely on 
some internal metrics without any knowledge of the 
outside environment. For example, a system may monitor 
its number of concurrent client connections to ensure 
that the number does not exceed a maximum threshold. 
Many current load balancing implementations are based on 
complex algorithms that apply only to a specific 
configuration . 

In order for a load balancing mechanism to operate 
successfully using internal metrics, a mathematical model 
of the expected behavior of the system must closely 
approximate the actual demands that are placed on the 
system. In a system in which the behavior of its devices 
and applications can be relatively easily monitored, an 
accurate model might be easily devised. However, in a 
highly distributed environment, the load demand can vary 
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greatly, and it is difficult to devise a load balancing 
mechanism based on internally derived metrics. 

Therefore, it would be advantageous to provide a 
method and system for automatically load balancing the 
demand on networked resources based on user-driven 
demand . 
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SUMMARY OF THE INVENTION 

A method, a system, an apparatus, and a computer 
5 program product for balancing demand for networked 
services in a distributed data processing system is 
presented. Each client is uniquely associated with a 
local service manager; one or more local service managers 
are located throughout the distributed data processing 
10 system, and each local service manager provides access to 
networked services for associated clients. Each local 
service manager is uniquely associated with a distributed 

I . : 

% service manager; one or more distributed service managers 

,%i 4 are located throughout the distributed data processing 

tt p 15 system, and each distributed service manager provides 

access to networked services for associated local service 
managers. A client sends a request for a networked 
!' service to its local service manager. The local service 

M= manager returns information about a matching service to 

!=p s 20 the client after finding a matching service that has 
Q characteristics that match parameters in the request. If 

::& the local service manager does not have information about 

a matching service, then the request is forwarded to its 
associated distributed service manager. If the 
25 distributed service manager does not have information 

about a matching service, then the request is broadcast 
to all distributed service managers. If the distributed 
service manager has two or more matching services, then 
it performs a load balancing operation to select a best 
30 service to be returned. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
5 invention are set forth in the appended claims. The 
invention itself, further objectives, and advantages 
thereof, will be best understood by reference to the 
following detailed description when read in conjunction 
with the accompanying drawings, wherein: 
10 Figure 1 illustrates a simplified diagram showing a 

large distributed computing enterprise environment in 
: ^ which the present invention may be implemented; 

•=B Figure 2 is a block diagram depicting a system 

j E £ management framework illustrating a software environment 

15 in which the present invention may be implemented; 
flLj Figure 3 is a block diagram depicting a 

Is: 

y configuration of software components that may used to 

implement the System Service Manager in a preferred 
U embodiment of the present invention; 

& 20 Figures 4A-4D are a series of flowcharts depicting a 

Q manner in which a client program can access a service 

within the System Service Management framework; 

Figure 5 is a block diagram depicting a snapshot of 
a set of services within a distributed computer 
25 environment that is implementing a System Service Manager 
framework; 

Figure 6 is a block diagram showing the manner in 
which a set of LSMs and DSMs build their relationships 
within a distributed system implementing a System 
30 Services Manager framework; 
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Figure 7 is a block diagram depicting the manner in 
which a getServiceO method may be invoked on a Local 
Service Manager; 

Figure 8 is a block diagram depicting the manner in 
which a getServices ( ) method may be invoked on a Local 
Service Manager to obtain advertised services; 

Figure 9 is a block diagram depicting some of the 
actions that are performed when a client tries to access 
a service remotely; 

Figures 10A-10B are block diagrams depicting some of 
the actions that are generally performed to create, 
maintain, and provide access to services within the 
System Service Manager framework; 

Figures 11A and 11B show the processing that is 
performed if a DSM terminates; and 

Figure 12 is a block diagram depicting a process for 
propagating information about services amongst DSMs . 
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With reference now to Figure 1, the invention is 
preferably implemented in a large distributed computer 
environment 110 comprising many thousands of nodes. The 
nodes will typically be geographically dispersed, and the 
overall environment is "managed" in a distributed manner. 
Preferably, the managed environment is logically organized 
into a series of loosely-connected managed regions 112, 
each of which has its own server 114 for managing local 
resources within the managed region. Multiple servers 114 
coordinate activities across the enterprise and permit 
remote site management and operation. Each server 114 
serves a number of gateway machines 116, each of which in 
turn support a plurality of endpoints or terminal nodes 
118. Server 114 may coordinate all activity within the 
managed region using a terminal node manager (not shown) . 

Various types of networks may be used to provide 
communications links between various devices and computers 
connected together within the distributed data processing 
system, such as an intranet, a local area network (LAN), 
or a wide area network (WAN) . The network may include 
permanent connections, such as wire or fiber optic cables, 
or temporary connections made through telephone or 
wireless communications. The distributed data processing 
system may include additional servers, clients, routers 
and other devices not shown. In the depicted example, the 
distributed data processing system may include the 
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Internet within the network representing a worldwide 
collection of networks and gateways. 

The distributed computer environment is managed as a 
form of client-server architecture with a system 
management framework. The system management framework 
includes both client components and server components. 
The client component is preferably a low cost, low 
maintenance application suite that is preferably 
"dataless" in the sense that system management data is not 
cached or stored by the client component in a persistent 
manner. Preferably, the system management framework uses 
an object-oriented approach that facilitates execution of 
system management services required to manage the 
resources in the managed region. Such services can be 
varied and may include, without limitation, file and data 
distribution, network usage monitoring, user management, 
and printer or other resource configuration management. 
Each service is represented in an appropriate manner by 
one or more objects throughout the distributed 
environment . 

In a large enterprise such as that illustrated in 
Figure 1, there may be one server per managed region with 
some number of gateways. For a smaller, workgroup- size 
installation configured on a single LAN, for example, a 
single server-class machine may be used as both the server 
and the gateway, and the client machines may run the low 
cost framework. For larger installations, the managed 
region may grow breadth-wise with additional gateways 
being used to balance the load of the endpoints or 
terminal nodes. 
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While a server, a gateway, and an endpoint may be 
software components that may be treated as logically 
separate entities residing on the same machine, each 
server, each gateway, and each endpoint are preferably 
5 separate machines or computers. For example, each 

computer may be a RISC-based workstation running the AIX 
(Advanced Interactive Executive) operation system. It may 
be assumed that a server is able to support hundreds of 
simultaneous network connections to remote machines. Each 
10 endpoint may also be a separate computer, such as an Intel 
Pentium-based computer running the Microsoft Windows 
sfc% operating system. Servers, gateways, and endpoint s may 

J3 also be represented by a variety of computing devices, 

\ si L such as mainframes, personal computers, personal digital 

;;F 15 assistants (PDAs), etc. 

rjj Figure 1 is intended as an example of a heterogeneous 

' computing environment and not as an architectural 

M= limitation for the present invention. The present 

invention could be implemented on a variety of networks, 
ijl 20 Those of ordinary skill in the art will also appreciate 
% that the hardware in Figure 1 may vary depending on the 

system implementation. The depicted examples are not 

meant to imply architectural limitations with respect to 

the present invention. In addition to being able to be 
25 implemented on a variety of hardware platforms, the 

present invention may be implemented in a variety of 

software environments . 

It is important to note that while the present 

invention is described in the context of a fully 
30 functioning data processing system, those of ordinary 

skill in the art will appreciate that the processes of 
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the present invention are capable of being distributed in 
the form of instructions in a computer readable medium 
and a variety of other forms, regardless of the 
particular type of signal bearing media actually used to 
carry out the distribution. Examples of computer 
readable media include media such as EPROM, ROM, tape, 
paper, floppy disc, hard disk drive, RAM, and CD-ROMs and 
transmission- type media, such as digital and analog 
communications links . 

With reference now to Figure 2, a block diagram 
depicts a system management component illustrating a 
software environment in which the present invention may 
be implemented. Each machine 210 within the system runs 
component 212 of the system management framework. 
Component 212 may be a multi -threaded runtime process that 
comprises several sub - component s : object request broker 
(ORB) 221; security service 223; and directory service 
225. Component 212 also includes object library 229 and 
service manager 231. Preferably, ORB 221 runs 
continuously, separate from the operating system. The ORB 
may be an instance of a CORBA ORB; CORBA is a 
specification for an object-oriented distributed computer 
systems management architecture provided by the Object 
Management Group (OMG) , a non-profit association of 
companies. Computer 210 also includes operating system 
235 and may contain some form of interprocess 
communication facility for supporting communication 
between server and client objects and processes. 

The present invention may be implemented on a 
variety of hardware and software platforms, as described 
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above. More specifically, though, the present invention 
is directed to automatically load balancing the demand 
for networked resources based on- user-driven demand. A 
System Service Manager (SSM) provides access to services 
5 for client-server entities or peer-to-peer entities on a 
network. Its main function is to manage the services to 
enable clients to access services in a uniform manner. 
The SSM preferably provides: decentralized operation such 
that the SSM requires little administrative intervention 
10 in small installations and limited administrative 

intervention in large enterprise deployments; scalability 
from few to many servers; optional administrative 
|*D grouping of services so that administrators can configure 

u& the SSM so that clients can only discover an intended set 

:;P 15 of services through a site policy; and robust access to 
j : y services that allows access by certain characteristics, 

• e.g., allowing a client to find an appropriate backup 

M= service if another service fails. 

The SSM supports services that must be started 
l:H 20 locally in order to have the ORB provide full 
!S : functionality, and the SSM also supports optional 

services that publish information outside of the scope of 
the ORB that may be used by clients, such as user 
applications, other services, etc. 
25 Services may be placed into three categories: local 

ORB services, which are services that provide internal 
services and are only valid in the local ORB scope; 
non-advertised services, which are instantiated on each 
ORB and, therefore, do not need to be advertised; and 
30 advertised services, which may be accessed from outside 
of the scope of the local ORB. 
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With reference now to Figure 3, a block diagram 
depicts a configuration of software components that may 
used to implement the System Service Manager in a 
preferred embodiment of the present invention. The 
5 System Service Manager (SSM) framework is logically built 
around two different types of components, the Local 
Service Manager (LSM) and the Distributed Service Manager 
(DSM) . The SSM uses the Configuration Service to enable 
customization of various LSMs and DSMs. The 
10 Configuration Service can also be used to retrieve a 
specific service configuration. 

Q An LSM is a piece of code running on each node of a 

! ft 

distributed computing environment. An LSM has the same 
M= lifecycle as the ORB, and an LSM's main responsibility is 

15 to keep track of the services defined locally and to 
!"U provide access to all of the services within the System 

Service Manager infrastructure. DSMs are located 
f a throughout the distributed computing environment and act 

!:£ as gateways for LSMs in order to access service 

^Fj 20 configuration information and LSM location information. 
=;y The DSMs also provide load balancing by minimizing the 

paths and the requests to access the services, as is 
described in more detail further below. The 
Configuration Service is a service that provides static 
25 information about the services, which are registered into 
the Configuration Service at installation time. 

ORB 310 supports System Service Manager 
functionality 320, which is a group of SSM components. 
The SSM components are shown within ORB 310 to indicate 
30 their reliance on the ORB to support their own 

functionality; however, the SSM components should not be 
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considered as integral to the ORB but rather as 
co-located with the ORB, more like components within 
service manager 231 shown in Figure 2. In this example, 
ORB 310 concurrently supports LSM instance 322, DSM 
5 instance 324, and Configuration Service component 

instance 326. It should be noted, however, that a given 
ORB supports at least one LSM and may support a DSM. 

The DSMs are designed to perform several tasks. The 
DSMs act as relays in the process of forwarding a request 
10 to get access to an SSM service. DSMs cache the proxies 
to the services in order to maintain a constant level of 
s;3 performance across a network, and DSMs can also locate 

: other DSMs within the same region. 

-tj — 

I 8 * DSMs also achieve a portion of the load balancing 

\\ 15 functionality by being distributed throughout the 

; | distributed computing environment in strategic locations. 

J Each DSM contains localization module 328 that enables 

!"T the load balancing functionality of a DSM to be 

\'& customized. Since the DSMs are distributed through the 

if] 

20 network, each DSM may execute on a unique hardware 

Ufa? 

i;3 platform with a unique set of supported services and with 

a unique demand load for requested services. Each DSM 
can be customized by establishing parameters within its 
localization module so that the DSM performs its load 

25 balancing duties in a manner that is tailored for the 
functionality desired from each DSM. 

After initialization, every LSM is connected to at 
least one DSM. The LSMs only manage the lifecycle of 
services that are defined locally. The LSM gets the 

30 service configuration information from the Configuration 
Service. The Configuration Service entries describe 
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properties related to the services as appropriate to the 
type of service. After being started by the ORB, the LSM 
keeps track of all the services defined by the 
Configuration Service and waits for client requests to 
access the SSM services. For example, at some point in 
time, an application on a node may request a service with 
particular properties, such as a local print service at a 
specific building location "BLDG1" and a specific floor 
location "FLR3 " . The LSM can determine whether a print 
service is available by searching for a service entry 
with those properties. If a matching service is not 
found, then the LSM can notify the requester that the 
requested service is not available. 

Various types of services may be active within the 
distributed computing environment at any given time. For 
example, services are installed and configured through 
the Configuration Service. Each service is delivered as 
one or more software components with an accompanying 
service template file that describes the service. 
Another service is the Planning and Distribution Service, 
which can use the service template file as input into the 
Configuration Service, thereby receiving the information 
that will later be used by the LSM to manage the service. 
While many types of services are present in the 
distributed environment, the present invention is 
directed to the functionality of distributed load 
balancing, and other services that are not critical to 
the operation of the present invention are not presented 
in detail . 

As noted above, services may be categorized as local 
ORB services, non-advertised services, and advertised 
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services. An LSM provides access to the SSM services 
based on the following considerations: an LSM does not 
provide access to local ORB services; an LSM provides 
access to non-advertised services only through requests 
5 based on an ORB identifier; and an LSM provides access to 
advertised services through requests based on both a 
service specification string and an ORB identifier. 

With reference now to Figures 4A-4D, a series of 
flowcharts depict a manner in which a client program can 
10 access a service within the System Service Management 
framework. A client receives references to services 
rH through a call to either a getService() method or a 

'rcr 

;*=D getServices ( ) method. If the client uses the 

getServiceO method, then a best selection for a service 
I;- 88 . 15 that matches the client's request is returned to the 
ry client when available. If the client uses the 

getServices ( ) method, then all services that match the 
client's request are returned to the client. The 
flowcharts shown in Figures 4A-4D describe the use of the 
J 20 getServiceO method. The use of the getServices ( ) method 
is described further below. 

Referring to Figure 4A, the process starts when a 
client issues a call to the directory service to locate 
an access manager (step 410) , and the client then 
25 receives a reference to the access manager (step 412). 
The access manager provides a single entry point or 
interface for accessing both services and component 
obj ects . 

The client then issues a call to the access manager 
30 through the getServiceO method implemented by the LSM 
(step 414) . The process then completes when the client 
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receives a reference for a matching service from the LSM 
(step 416) . However, if no matching service were 
available, then the client would receive some type of 
status from the LSM indicating that a service that 
matches the request is not available. 

Referring to Figure 4B, a flowchart shows the manner 
in which an LSM processes a request from a client. The 
process begins when the getServiceO method of the LSM is 
invoked by a client (step 420) . The LSM makes a 
determination whether or not a service known to the LSM 
has parameters that match the service characteristics in 
the request (step 422) . If so, then the LSM returns a 
reference to the matching service to the requesting 
client (step 424), and the process is complete. 

If the LSM does not have any knowledge of a service 
that would match the request, as determined in step 422, 
then the LSM forwards the request to its DSM (step 426) . 
At some later time, the LSM receives a reference to a 
service from the DSM that fulfills the request (step 
428) . The LSM then returns the reference from the DSM to 
the requesting client (step 430) , and the portion of the 
process on the LSM is complete. However, if the LSM does 
not receive a references from its DSM, the LSM may inform 
the requesting client with an appropriate status message. 
Alternatively, the requesting client may timeout requests 
to the LSM. 

Referring now to Figure 4C, a flowchart shows the 
manner in which a DSM processes a request from one of its 
LSMs . The process begins when the DSM receives a request 
from an LSM (step 440) . The DSM checks whether or not it 
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has any cached proxies for one or more services that have 
characteristics that match the parameters specified in 
the request (step 442) . If so, then the process branches 
for appropriate processing. 
5 If the DSM does not have any knowledge of any 

matching services, then the DSM publishes or broadcasts a 
message to all DSMs to search for a service that matches 
the request (step 444) . At some later time, the DSM 
determines whether or not the DSM has received one or 
10 more references from other DSMs for services that match 
the request (step 446) . If not, then the DSM may 
optionally return a status message to the LSM to inform 
the LSM that no matching services have been found (step 
448) , and the portion of the process within the DSM is 
15 then complete. 

If the DSM has received at least one reference for a 
matching service from another DSM, then the DSM caches 
the reference or references (step 450) . The DSM then 
makes a determination whether or not the DSM has 
;;D 20 knowledge of multiple services that fulfill the original 
i"3 request (step 452). 

If the DSM has knowledge of multiple services that 
can fulfill the request, then the DSM performs an 
internal load balancing process to obtain the best 
25 selection of a single service (step 454) . At this point, 
the DSM may invoke its localization module, which 
provides parameters to be used during the load balancing 
process. When more than one matching service is known at 
the DSM level, the localization module can compare 
30 characteristics of the matching services with specified 
parameters in the localization module. 
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For example, the localization module may inform a 
load balancing routine to examine the hop count (HC) , the 
bottleneck link speed (BLS) , or return trip time (RTT) 
for a matching service. A hop count is determined from 
5 the number of discreet transmissions, or hops, between 

the requester or DSM and the device on which the matching 
service resides, i.e. the number of times which a packet 
must be routed along a network path. The bottleneck link 
speed is determined from the slowest transmission speed 
10 of any link within the network path between the requester 
or DSM and the device on which the matching service 
resides. The return trip time is the amount of time to 
:0 receive a response from a service at a requester or DSM, 

LjjL which may depend on both the HC or BLS. 

: P 15 The localization module may examine the HC, BLS, or 

y RTT, or some combination of these or other 

; ^ network-related parameters or metrics, in order to 

determine which matching service seems to be the best 
selection for the given requesting client. It should be 
lih 20 noted that the HC, the BLS, or the RTT may be determined 
% at network configuration time or in real-time by 

gathering this information at the DSM when performing a 
load balancing operation. 

After selecting either the best matching service, as 
25 determined in step 454, or the only matching service, as 
determined in step 452, the DSM returns a reference for a 
matching service to the LSM (step 456), and the portion 
of the requesting process within the DSM is complete. 
Referring now to Figure 4D, a flowchart shows the 
30 manner in which a DSM processes a broadcast request from 
another DSM. The process begins when the DSM receives a 
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broadcast request from another DSM (step 460) . The DSM 
determines whether it has any cached proxies for one or 
more matching services already available at the DSM (step 
462). If not, then the broadcast request may be ignored, 
5 and the process is then complete. 

If the DSM has one or more matching services, then 
the DSM returns references for all matching services to 
the broadcasting DSM (step 464), and the process is 
complete. 

10 With reference now to Figure 5, a block diagram 

depicts a snapshot of a set of services within a 
distributed computer environment that is implementing a 
System Service Manager framework in accordance with a 
^ preferred embodiment of the present invention. System 

%} 15 500 merely illustrates an exemplary system and some of 
! ^ the processing within the system; the manner in which 

;: services are accessed is shown in more detail further 

below with respect to Figures 6-12. 

System 500 contains nodes 510, 520, 530, 540, 550, 

i.fi 

rg 20 and 560, which contain LSMs 511, 521, 531, 541, 551, and 
i:i=? 561 respectively. Service SO does not need to be 

advertised because it is running on all of the nodes; 
therefore, the only way to access service SO is through 
an ORB ID that specifies the target node. Services S1-S4 
25 are advertised, and DSM 532 is maintaining proxies P1-P4 
for services S1-S4, respectively. When client 563 tries 
to access service SO on node 540 by specifying the proper 
ORB identifier, the request is forwarded directly to 
target node 540 by LSM 561. For that request, DSM 532 is 
30 not involved, and LSM 561 handles the whole request. 
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When client 563 tries to access the advertised service S2 
through a service specification string, the request is 
forwarded to DSM 532, and DSM 532 returns a cached proxy 
P2 to LSM 561, which is returned to client 563. 

With reference now to Figure 6, a block diagram 
shows the manner in which a set of LSMs and DSMs build 
their relationships within a distributed system 
implementing a System Services Manager framework in 
accordance with a preferred embodiment of the present 
invention. Every time an ORB is initialized, the ORB 
also starts an instance of an LSM, to which it passes a 
DSM reference. The DSM may be local or remote according 
to the environment configuration. When a DSM and a LSM 
are co- located on the same node, the LSM receives the 
reference of the local DSM instead of a reference to a 
remote DSM. 

System 600 contains nodes 610, 620, 630, 640, and 
650, which contain LSMs 611, 621, 631, 641, and 651, 
respectively. Node 610 contains DSM 612, and node 640 
contains DSM 642. LSMs 611, 621, and 631 receive a 
reference to DSM 612, whereas LSMs 641 and 651 receive a 
reference to DSM 642. 

With reference now to Figure 7, a block diagram 
depicts the manner in which a getServiceO method may be 
invoked on a Local Service Manager. System 700 contains 
nodes 710 and 720, which contain LSMs 711 and 721, 
respectively. LSM 721 manages service SI and has proxy 
PI for service SI. Node 710 also contains DSM 712, which 
has a cached copy of proxy PI. Client 723 requests 
access to service SI located on the same machine using 
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the getServiceO method. Since service SI is a service 
that has been previously started locally, a match is 
found by LSM 721, and proxy PI is returned to client 723 
without any interaction with DSM 712. 

With reference now to Figure 8, a block diagram 
depicts the manner in which a getServices ( ) method may be 
invoked on a Local Service Manager to obtain advertised 
services. When a request is performed using the 
getServices ( ) method, all of the DSMs are called to check 
if they maintain a proxy that matches the input criteria. 
All of the matching proxies are then returned to the 
caller. A client may use the getServices ( ) method 
instead of the getServiceO method if the client desires 
to perform its own selection from among multiple 
available services . 

System 800 contains nodes 810, 820, and 830, which 
contain LSMs 811, 821, and 831, respectively. LSM 821 
manages service SI and has proxy PI for service SI. Node 
830 contains DSM 832. Node 810 also contains DSM 812, 
which has a cached copy of proxy PI. LSM 811 also 
manages an instance of service SI' , and DSM 812 has a 
cached copy of proxy PI' . 

Client 823 invokes the getServices ( ) method for 
services with particular criteria, which happens to match 
service SI on node 820. Since service SI is a service 
that has been previously started locally, a match is 
found by LSM 821, and LSM 821 returns proxy PI that 
matches the criteria locally. The request is then 
forwarded to DSM 812, which also forwards the request to 
all of the other DSMs. DSM 812 also maintains a proxy 
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PI' to a service SI' that matches the requested criteria, 
and proxy PI' is also returned to client 823. Since DSM 
832 does not maintain any references to a service SI or 
any services that fulfill the request, DSM 832 does not 
5 respond. 

With reference now to Figures 9A-9B, block diagrams 
depict some of the actions that are performed when a 
client tries to access a service remotely. System 900 
contains nodes 910 and 920, which contain LSM 911 and 
10 921, respectively. Node 910 also contains DSM 912, which 
shares proxy PI with LSM 911 that is supporting service 
£3 S2 . 

: -U Referring to Figure 9A, client 923 sends a request 

l p to access service S2 to LSM 921, which checks an internal 

y 15 table to determine if it maintains a proxy to service S2 
:! p that matches the criteria of the request. After LSM 921 

j.^ determines that it has no matching proxy, LSM 921 checks 

^ if DSM 912, to which it is connected, holds a reference 

rfj to service S2 . DSM 912 knows about service S2, so it 

20 returns proxy P2 for service S2 to LSM 921. Before 
returning the proxy, DSM 912 may check to determine 
whether service S2 is still alive by issuing a request to 
service S2 and checking if service S2 responds to the 
request . 

25 Referring now to Figure 9B, DSM 912 has multiple 

cached proxies P2', P2'', and P2''' from which DSM 912 
may select a best service after performing an internal 
load balancing process. Each of the proxies P2', P2'', 
and P2''' have been previously cached when DSM 912 
30 attempted to fulfill prior requests and received 
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references to other services from other DSMs within the 
network (not shown) . 

With reference now to Figures 10A-10B, block 
diagrams depict some of the actions that are generally 
performed to create, maintain, and provide access to 
services within the System Service Manager framework in 
accordance with a preferred embodiment of the present 
invention. In both Figures 10A-10B, system 1000 contains 
nodes 1010, 1020, 1030, 1040, and 1050, which contain 
LSMs 1011, 1021, 1031, 1041, and 1051, respectively. LSM 
1021 manages service SI and has proxy PI for service SI. 
Node 1040 contains DSM 1042, which shares proxy P2 with 
LSM 1041 that manages service S2 . Node 1010 also 
contains DSM 1012, which has a cached copy of proxy PI. 
LSMs 1021 and 1031 are connected to DSM 1012. LSM 1041 
and LSM 1051 are connected to DSM 1042. 

Referring to Figure 10A, when client 1033 attempts 
to access service S2, a request is sent to LSM 1031, 
which does not know about service S2 , so the request is 
forwarded to DSM 1012. Since DSM 1012 does not have any 
knowledge about service S2, it publishes or broadcasts a 
message looking for a DSM that has knowledge about 
service S2 . DSM 1042 knows about service S2, so DSM 1042 
returns all available information about it. DSM 1012 
then caches a copy of proxy P2 locally and returns proxy 
P2 to LSM 1031, which is returned to client 1033. If 
client 1053 desires access to service SI, a similar 
process would be followed, resulting in proxy PI being 
stored by DSM 1042 . 



24 

i 

AUS9-2000-0483-US1 

Referring to Figure 10B, after running for a while, 
the system will reach equilibrium with proxies to a given 
service equally distributed among all the DSMs. Figure 
10B shows proxy P2 cached at DSM 1012 and proxy PI cached 
5 at DSM 1042. 

With reference now to Figures 11A and 11B, two 
diagrams show the processing that is performed if a DSM 
terminates. Each LSM implements a monitoring mechanism 
that detects if the DSM to which it is connected is up 
10 and running. System 1100 contains nodes 1110, 1120, 
1130, 1140, and 1150, which contain LSMs 1111, 1121, 
Q 1131, 1141, and 1151, respectively. Node 1140 contains 

,% U DSM 1142, and node 1110 also contains DSM 1112. LSMs 

J 1111, 1121, and 1131 are connected to DSM 1112, and LSM 

15 1141 and LSM 1151 are connected to DSM 1142. 

iu 

i8 p When LSM 1151 detects that DSM 1142 has failed, LSM 

!^ 1151 publishes or broadcasts a message to get a reference 

I s * to a new DSM. Once a new reference is received, LSM 1151 

f;h can upload all of the information related to the services 

% 20 that LSM 1151 is managing. In Figure 11B, LSM 1151 has 
received a reference to DSM 1112. 

With reference now to Figure 12, a block diagram 
depicts a process for propagating information about 
services amongst DSMs. System 1200 contains nodes 1210, 
25 1220, 1230, and 1240. Node 1210 contains DSM 1212, and 
node 1220 contains LSM 1221. Node 1230 contains DSM 
1232, and node 1240 contains LSM 1241 and DSM 1242. LSM 
1221 manages service SI, and LSM 1241 supports client 
1243. LSM 1241 is connected to DSM 1242, and LSM 1221 is 
30 connected to DSM 1212. 
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Service SI is started through LSM 1221 and 
advertised by DSM 1212. When client 1243 wants access to 
service SI, LSM 1241 forwards the request to DSM 1242 
because LSM 1241 does not have any knowledge of service 
SI. As DSM 1242 does not have any references for service 
SI, DSM 1242 tries to contact a DSM within the 
environment that may know about service SI. DSM 1242 
publishes or broadcasts a REQUEST_FOR_ONE_SERVICE 
message, putting its ORB identifier into the source field 
of the message and a null in the destination field. The 
null means that all DSMs must check whether they can 
fulfill the request in the message, and all DSMs receive 
the message. DSM 1232 receives the message but discards 
it because it does not know about service SI. DSM 1242 
also receives the message and discards it because the Oid 
is its own Oid. However, DSM 1212 will receive and 
process the message because it knows about service SI. 

DSM 1212 publishes a REPLY_TO__ONE_SERVICE message 
with the service information for service SI. The source 
Oid is swapped to the destination field, and DSM 1212 
puts its Oid in the source field of the message. The 
message is then published or broadcast, which is then 
received by every DSM in the environment. DSM 1212 and 
DSM 1232 discard the message because the Oid in the 
destination field does not match its Oid. DSM 1242 
processes the message because the destination Oid matched 
its internal Oid. It stores the SI service information 
locally and returns the proxy to LSM 1241, which then 
returns it to client 1243. 
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Services can also be removed from the environment. 
If an LSM gets a proxy from a DSM, it may test it and 
discover that the proxy is invalid. In this case, the 
LSM calls a deprecateServiceRef ( ) method on the DSM to 
5 which it is connected. The DSM then publishes or 

broadcasts a DEPRECATE_SVC_INFO message to the other 
DSMs . By setting the destination field to null, every 
DSM will check the message, and every DSM subsequently 
checks its internal repository to see if any service 
10 information matches the request. If so, then the DSM 
invalidates its internal entry. 
^ The advantages of the present invention should be 

^0 apparent in view of the detailed description of the 

invention that is provided above. The processing 
^ 15 required for fulfilling a request for a service is 

fjj distributed through Local Service Managers (LSMs) and 

'.fc 

Distributed Service Managers (DSMs) . The present 
M= invention automatically load balances according the scope 

!.£ of the requests issued by the clients connected to the 

20 distributed environment. A networked service's 
j5 visibility is propagated based on matching criteria and 

not according to the load of the machine supporting the 

services . 

The description of the present invention has been 
25 presented for purposes of illustration but is not 

intended to be exhaustive or limited to the disclosed 
embodiments. Many modifications and variations will be 
apparent to those of ordinary skill in the art. The 
embodiments were chosen to explain the principles of the 
30 invention and its practical applications and to enable 
others of ordinary skill in the art to understand the 



AUS9-2000-0483-US1 

invention in order to implement various embodiments with 
various modifications as might be suited to other 
contemplated uses. 
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